home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / tex-k / tex-k-archive.past / 1994.12.gz / 1994.12 / 000040_peta@Whippet.McRCIM.McGill.EDU_Wed Dec 7 11:47:52 1994.msg < prev    next >
Internet Message Format  |  1994-12-30  |  1KB
  1. Received: from Lightning.McRCIM.McGill.EDU by cs.umb.edu with SMTP id AA24037
  2.   (5.65c/IDA-1.4.4 for <tex-k@cs.umb.edu>); Wed, 7 Dec 1994 16:48:09 -0500
  3. Received: from Whippet.McRCIM.McGill.EDU by Lightning.McRCIM.McGill.EDU (8.6.9) with ESMTP
  4.     id <199412072145.QAA26516@Lightning.McRCIM.McGill.EDU>; Wed, 7 Dec 1994 16:45:34 -0500
  5. Message-Id: <199412072145.QAA26516@Lightning.McRCIM.McGill.EDU>
  6. To: tex-k@cs.umb.edu
  7. Subject: [xdvi18d] Excessive use of gs...Grrrr...
  8. Date: Wed, 07 Dec 1994 16:47:52 -0500
  9. From: Peter Whaite <peta@Whippet.McRCIM.McGill.EDU>
  10.  
  11. First thanks to everyone who pointed to the patches for gs2.61.  That fixed
  12. that.  
  13.  
  14. However why does xdvi18d call upon gs EVERYTIME some part of the screen needs
  15. to be refreshed?   Oh I guess its just passing the window properties to gs so
  16. gs can render directly to the right portion of the screen.
  17.  
  18. The previous version we had (xdvik version 1.8) was very good in this regard.
  19. I guess it used gs to render to a cached bitmap so redisplaying the page was
  20. very snappy.
  21.  
  22. I find the new behaviour incredibly annoying.  With big images (and we often
  23. do have >1Mb grayscale images to render) it is totally unacceptable .  No doubt
  24. caching uses considerably more memory but it is well worth it in our case.
  25.  
  26. Is there someway to configure back the old behaviour.
  27.